Thanks. But will this work in all cases? Does it work regardless of the example list delimiters used? e.g.

@a. one

(@b) two

No, your example will unfortunately not work in any implementation of DOCX writer that supports shared identifier (as the method of sequence continuation). Or more precisely - the numbering will work but the delimiter will be the same.

Microsoft Word only supports a single styling per identifier. In your example you would have to choose between one or the other delimiter. The only way to achieve combination of both delimiters in Microsoft Word (or in any other word processing software supporting OpenXML) is either by:

1. breaking the sequence (what Pandoc currently does and what negatively affects editing) or
2. leveraging a named sequence instead of a numbering (which has other minuses).

The only possible improvement within the given constraints would be to decide on what element of the sequence entered in markdown defines the type of the delimiter. The first one seems like the logical choice - if you agree with this I could add this to the implementation.

As an aside, I am wondering how often does it actually happen that inconsistent use of delimiters in the process of numbering content is actually the desired end result. It is somewhat common that a different style is used when referencing the numbered item, but with the numbering one usually chooses a style and sticks with it throughout the document. I am course referring to the different styles for the same (single) sequence here (a case relevant for example_lists) not to a combination of different styles and sequences (out of scope in this case).

The first one seems like the logical choice - if you agree with this I could add this to the implementation.

Seems reasonable to me.

I am wondering how often does it actually happen that inconsistent use of delimiters in the process of numbering content is actually the desired end result.

Not very often, if ever. My guess is that we'll be okay if we let the first one control the delimiters on the rest.

With a few additional changes this gives the end result in line with the above (first Example sets the delimiters):

I don't think we actually want that behavior. If you try with pandoc -t plain you'll see that it doesn't work that way in other formats. Rather, there is a single sequence of numbers, but they get different delimiters depending on what was in the original.

I think we should keep the single sequence. IF it's convenient to preserve the delimiters, this could be nice, but as noted above it's unlikely to be a problem in practice if we just use the first example list item's delimiter for all the items in the sequence.

It must be noted that the effect of the proposed change is exactly what you describe in the second paragraph - and what I understood you considered reasonable in the post before last:

• a) There is a single uninterrupted sequence in the document
• b) Delimiter of this sequence is set by the first occurrence
• c) The result is an idiomatic document in the target format

Unfortunately, as mentioned, there is currently no way of implementing an uninterrupted numbering in OpenXML/DOCX (or in OpenDocument/ODT for that mater) that would enable both:

1. an editable numbering - allowing insertion of new items (with auto-renumbering), customizing numbering style etc. as well as
2. enable different delimiters within that same numbering sequence for a specific (sub)group of the sequence

I understand that the behavior that limits the Examples to 1 delimiter throughout the document is not shared between all formats. But neither are other functionalities - e.g. probably nobody ever complained that there is an option to:

• (i) add a table of content that allows refreshing in Microsoft Word or
• (ii) use idiomatic numbering of headings in a DOCX template or
• (iii) use native numbering of figures and tables or
• (iv) import or output editorial comments of the content or
• (v) ...

Formats that primarily target plain text editors do no support the functionally listed above due to obvious reasons. One could hardly say that insisting on the lowest common denominator would be beneficial on the other hand. Furthermore, one could even say that there is a reason that most (all?) word processors support changing only the attributes (e.g. delimiter, spacing) of the entire numbering sequence (and not a subset of it). For everything else there is support for free-style named sequences where few limits exists regarding formatting etc.

Lastly, perhaps also worth point out is that Pandoc's manual does not state anywhere that one can mix delimiters within a single Example sequence, nor does it list an example of such behavior. If there were to be a change enforcing a single delimiter for other formats, it would therefore not break any specification. And, as discussed above, it is hard to find a good use case for inconsistent numbering of items within a single sequence.

I understood that you support the implementation in this pull request for this specific format (please correct me if not). Hopefully the arguments above also show that for at least some if not all Pandoc supported format the Examples implementation should follow similar logic.

Oh, I'm sorry, I misread your example. I didn't realize that you were using regular list items, not example list items. (So I thought that the example list numbering was restarting when you changed delimiters, and that's what I was objecting to.)

So, yes, this is fine! And I'm sorry you had to write all those paragraphs.

Thanks, merged.